-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Sign rework api (part 1 of 2 for sign rework PR) #706
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did an initial look through, to properly understand the AbstractMovecraftSign
I think I'll need to try my hand at updating a sign or two.
// DONE: In 1.21 signs can have multiple sides! This requires us to pass the clicked side through or well the relevant lines and the set method for the clicked side => Resolved using the SignWrapper | ||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean a two-sided sign effectively acts like two signs to Movecraft?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, each side can have different text, which makes each side act as individual side.
So basically it would be like putting two one sided signs with their backs to each other.
I would like to keep it like this, it's useful for hanging cruise signs or for peripheral stuff like contacts and Status
* - SignChangeEvent | ||
* - PlayerInteractEvent, if the clicked block is a sign | ||
* - CraftDetectEvent | ||
* - SignTranslateEvent (if the sign is a subclass of AbstractCraftSign) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overhead of the Bukkit event system is significant when translating signs. Is it possible that this system could replace it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, i could change it so it has a "onTranslate" function in the base class. I'd still make it collect "all the same signs" per type and then calling their "instance", so in effect what it does right now, but without the bukkit event being the "bridge".
api/src/main/java/net/countercraft/movecraft/sign/AbstractMovecraftSign.java
Outdated
Show resolved
Hide resolved
api/src/main/java/net/countercraft/movecraft/sign/AbstractMovecraftSign.java
Outdated
Show resolved
Hide resolved
api/src/main/java/net/countercraft/movecraft/sign/AbstractCraftSign.java
Outdated
Show resolved
Hide resolved
public void onCraftDetect(CraftDetectEvent event, AbstractSignListener.SignWrapper sign) { | ||
// Do nothing by default | ||
} | ||
|
||
public void onSignMovedByCraft(SignTranslateEvent event) { | ||
// Do nothing by default | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those implementations? Not really, but the functiosn should be there as at least abstract. I use the CraftDetectEvent callback to handle stuff like setting the name, displaying the Status and so on on mount (latter is not fully working yet but eventually)
The other is just the callback for when the sign was moved by the craft, updating stuff and such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will leave them in as that for now. Not all craft signs require them but we should give the opportunity to react to that
api/src/main/java/net/countercraft/movecraft/sign/AbstractMovecraftSign.java
Show resolved
Hide resolved
/*if (signWrapper.block().getBlockData() instanceof Directional) | ||
craft.setCruiseDirection(CruiseDirection.fromBlockFace(((Directional) sign.getBlockData()).getFacing())); | ||
else | ||
craft.setCruiseDirection(CruiseDirection.NONE); | ||
craft.setCruiseDirection(CruiseDirection.NONE);*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove commented out code, Git keeps it around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, will do that when i work on the fork again
api/src/main/java/net/countercraft/movecraft/events/SignTranslateEvent.java
Outdated
Show resolved
Hide resolved
api/src/main/java/net/countercraft/movecraft/events/SignTranslateEvent.java
Outdated
Show resolved
Hide resolved
For examples on the implementations you can just check the (older) PR which also has the implementations (#679 ) or the testbranch in my fork |
*/ | ||
public abstract class AbstractMovecraftSign { | ||
|
||
private static final Map<String, AbstractMovecraftSign> SIGNS = Collections.synchronizedMap(new HashMap<>()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this whole registry system outside of the actual AbstractMovecraftSign
implementation, and use a singleton instead of static? Perhaps a MovecraftSignRegistry
? we can make it accessible from the Movecraft
instance for now. With our move towards DI/inversion of control, we should avoid adding new static singletons like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once it's merged. We already have some registry thing used in the DataTags topic, so if we add a generic registry implemtnation (i have one somewhere) we should adjust that too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think a generic registry is a good idea - its just a naming convention. I just would prefer to seperate the registration system from the registrars
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant a generic registry base class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a small generic registry base class that can be used for multiple registries, does it fit your needs?
(cherry picked from commit fd70b50)
Adressed your points |
(cherry picked from commit 54336e5)
(cherry picked from commit 27b9491)
(cherry picked from commit f7fd65e)
(cherry picked from commit 6a09a70)
(cherry picked from commit 8e7f1bf)
(cherry picked from commit 08b4e6d)
(cherry picked from commit e3a730c)
(cherry picked from commit a426bcf)
(cherry picked from commit 869cb5a)
(cherry picked from commit c345a25)
(cherry picked from commit 834794f)
(cherry picked from commit 2454f78)
(cherry picked from commit dc459d2)
(cherry picked from commit 77bb394)
(cherry picked from commit 397e7fe)
(cherry picked from commit 441452c)
(cherry picked from commit 0433e31)
(cherry picked from commit 0ce7710)
PR is ready for new review, it is now at the same state as my own testing branch which is being run since 2 weeks on a different server and so far works good |
Describe in detail what your pull request accomplishes
As discussed with @oh-noey the original PR (#679 ) is being splitted into two parts.
The first part (this PR) being the necessary API classes and changes ONLY.
That contains the base classes for all signs as well as their registration and the sign wrapper shenanigans.
This does not yet contain the necessary changes to TranslationTask.java and RotationTask.java as those changes need to be looked at again. Most of the change is switching to a call to the signListener instance though.
Checklist